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ABSTRACT 


This document describes a Data Simulation Computer 
Program which generates test tapes to be used for debug- 
ging or testing satellite telemetry computer programs. 
Test tapes may be generated for all presently defined sat- 
ellite projects. Besides being used directly by program- 
mers, analysts, and experimenters, the test tapes can be a 
valuable aid to NASA personnel responsible for attesting to 
the adequacy of computer programs developed under con- 
tract. Over-all benefits offered by the Data Simulation 
Computer Program are a substantial increase in the degree 
of assurance that a given computer program is adequately 
debugged prior to actual use, a reduction in the effort re- 
quired by the programmer in generating test data, the 
elimination of erroneous test data due to clerical er- 
rors, and a reduction in the time required for debugging 
programs. 
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A GENERALIZED SATELLITE TELEMETRY 
DATA SIMULATION PROGRAM 

by 

Bernard G. Narrow and Richard C. Lee 
Goddard Space Flight Center 


INTRODUCTION 

Computer processing of satellite telemetry data plays a vital role by assisting the experi- 
menter in deducing the maximum amount of information from a given experiment. Typically, com- 
puter processing is employed in the following stages: 

First Stage - After the analog data recorded at the world-wide network of data acquisi- 
tion stations is converted to a digital tape suitable for computer processing, the data are 
edited, partially verified, and reformatted by the computer. 

Second Stage - The edited data, consisting of a mixture of multiple experiments in the satel- 
lite, is decommutated; i.e., segregated in the computer by related experiments for recording 
on separate magnetic tapes. 

Third and Subsequent Stages - The separate experiment data tapes are subjected to a number 
of computer programs peculiar to the given experiment data. Normally the functions per- 
formed are data validation, calibration, smoothing, curve fitting, interpolating, time and 
spatial correlation, and data display. 

Each of the stages described uses one or more computer programs, differing from one satellite 
to another and from one experiment to another. For the Orbiting Geophysical Observatory (OGO) 
series satellites which have 20 experiments each, it is conservatively estimated that at least 70 
computer programs were prepared for each of the satellites. 

Many different groups are involved in the preparation of computer programs. The Information 
Processing Division at the Goddard Space Flight Center is responsible for the programs associated with 
the first two stages and partially with the third and subsequent stages described above. Experi- 
menters, both those within GSFC and those affiliated with other government agencies and univer- 
sities, are responsible for the bulk of the programs pertaining to the third and subsequent stages. 

In a large percentage of cases, the actual programming is done under contract. 



PROGRAM TESTING 


Computer programs vary considerably both in size and complexity. Common to all programs, 
however, is the task of debugging or testing each program to determine that the program structure 
is logically correct and that all instructions are correct and properly interrelated. Program test- 
ing is not only one of the more important factors in developing operational computer programs, 
but also is perhaps the most prone to underestimation of difficulty and time necessary for comple- 
tion. Because of the many combinations and permutations of conditions inherent in a given pro- 
gram, it is practically impossible to test all possible conditions which may arise in actual practice. 
As a result, it is not uncommon that a program which has been operating successfully for many 
months is one day found to be inoperative because of a rare set of conditions which was not properly 
covered in the computer program. 

To debug programs that are to process satellite telemetry data, one or more of the following 
sources of data have been used: 

Data generated manually by the programmer, 

Data acquired from the satellite during ground testing, and 

Actual data tapes acquired from previous satellites which have the same basic telemetry 
format. 

The first two sources have a major limitation in that the data obtained therefrom do not ade- 
quately reflect the perturbations present in actual telemetry data. Such perturbations, or noise, 
can be directly introduced in any of the following links between the sensing of the data in the satel- 
lite and the subsequent input of the data to the computer: 

Experiment noise, 

The satellite telemetry system, 

The satellite tape recording system, 

The free space channel between the satellite and the ground acquisition station, 

The receiving and ground recording systems at the ground acquisition station, and 
The signal conditioning and conversion systems at GSFC. 

The use of the actual data from previous satellites to debug programs for future satellites 
partially overcomes the above limitation, but it too is of limited utility. In many cases, none of 
the data available from previous satellites have a suitable format or have been obtained via 
the same set of data links as the given satellite. Another limitation is that information concerning 
the specific type and location of the noise perturbations within a given data tape is not available to 
the programmer. Hence, it is possible that the program will not correctly detect a particular 
perturbation present in the data and that the programmer will not be aware of this deficiency. 


2 


Since the previously described sources do not permit computer programs to be debugged with 
a high degree of confidence, another source has been developed, namely, a Data Simulation Com- 
puter Program. Through this program, data can be made available to the programmer which will 
realistically take into account the various specified noise conditions. Although this will not pro- 
vide complete assurance that programs are fully debugged prior to satellite launch, it should per- 
mit a substantial increase in the degree of assurance over that which may be achieved from other 
sources. Other benefits are a reduction in effort required by the programmer in generating test 
data, a reduction of errors in the test data due to clerical or keypunch errors, and a speed-up in 
the debugging cycle by circumventing the large degree of dependency on data acquired during 
ground testing of the satellite. 

Besides being used by the programmer and analyst for testing programs prepared by NASA 
personnel, the Data Simulation Program can be a valuable aid to persons responsible for accepting 
programs developed by contractor personnel. At present almost complete reliance is placed on 
the contractor for attesting to the operational readiness of these programs. With the existence of 
the Data Simulation Program, this need no longer be the case. NASA personnel can specify a com- 
prehensive set of test data to be turned over to the contractor for checking out the programs in- 
volved. This could serve as effective criteria for attesting to program readiness prior to ac- 
ceptance of the program. 


DESIGN OF DATA SIMULATION PROGRAM 

The objective in the design of the Data Simulation Program was to create a single program 
which could be used for most future satellites. This called for a very high degree of flexibility 
in order to account for differences in telemetry systems and formats, varying degrees and 
types of noise conditions, differences in experiment data characteristics, differences in tape for- 
mats used by the different experimenters, etc. Taking all of these factors into account fortunately 
did not turn out to be a horrendous programming task, and therefore it was feasible to proceed 
and implement the generalized telemetry data simulation system. 

Factors which make it feasible to specify a general set of rules under which different satellite 
data can be adequately defined by the user are: 

a. Commonality of basic elements; all time- multiplexed satellite telemetry formats can be 
specified in terms of channels, frames, subcommutation and supercommutation, and related 
ground time. 

b. A large percentage of experiment data characteristics can be suitably portrayed by a rela- 
tively small number of data generation routines, e.g., sine waves, values with known addi- 
tive noise probability distributions, consecutively increasing or decreasing values, stair- 
case increasing or decreasing value, etc. 

c. Common impact due to perturbations; all satellite data are vulnerable to sensor noise, 
transmission noise, spacecraft and ground equipment malfunction, and equipment operator 


errors. 
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Through the combination of design elements incorporated into the program (e.g., general 
purpose routines; input parameters to define the telemetry format, data characteristics and noise 
conditions; and options for users to insert their own coding in the program), all the data needed to 
comprehensively test the multitude of programs prepared for a given satellite can be provided by 
the Data Simulation Program, which is described next. 


DATA SIMULATION PROGRAM 

Presented here is a general system description which highlights the major characteristics of 
the product. A user’s manual is available to provide a full description of the capabilities of the 
program. The manual contains detailed instructions for preparing input specifications, and il- 
lustrates how particular formats and conditions may be defined. 

Process Flow 

The Data Simulation Program is written 
for the UNIVAC 1107 computer. As shown in 
Figure 1, the user provides a deck of punched 
cards containing all definitions and parameters 
for the simulation, as well as user subroutines 
for special computations. The primary output 
is a digital tape containing the simulated data. 

A secondary output is a listing containing input 
parameters, selected data channel and record 
printouts, errors inserted during simulation, 
and summary statistics for each simulated file. 

Format Definition 

A simulated tape may have up to nine data files, and may be recorded with odd or even parity 
and with high or low density. The hierarchy of the file organization is file, record, frame, and 
channel. The length of a given file is governed by the start and stop times, which are input param- 
eters. Record lengths may vary up to 360,000 bits and are determined by the number of frames 
per record and the number of bits per frame, which are also input parameters. 

A frame consists of a number of fixed word length channels which can vary in length from 
6 bits up to 36 bits for different files. A channel may contain either experiment data, a frame 
synchronization pattern, a subcommutator identifier pattern or counter, spacecraft clock readings, 
ground time, or data quality flags. Any ordering of channels within a frame is permissible, thereby 
providing full flexibility in data formatting. Two examples out of the many possible formats that 
can be obtained from the AE-B satellite telemetry format (Figure 2) are illustrated in Table 1. 


UNIVAC 1107 USER'S 



DEFINED FOR LISTING OF: 

THE RUN FORMAT DEFINITION 

PARAMETERS 
ERROR CONDITIONS 
SELECTED DATA 
RECORDS & CHANNELS 
STATISTICS 

Figure 1— Data simulafion flow diagram . 
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A comprehensive set of options concerning 
noise perturbations is also available to the 
user. Such things as transmission noise, sig- 
nal blanking, bit slippage, sensor noise, satel- 
lite clock and ground time discontinuities, loss 
of synchronization during analog- to-digital con- 
version, and equipment operator errors may be 
selected in any combination, and the composite 
impact is reflected in the simulated output data. 
Brief descriptions of the options concerning the 
experiment data, spacecraft clock and ground 
time, and the various perturbations are given 
next. 
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Figure 2— Atmosphere Explorer-B telemetry format. 


Table 1 

Two Examples of Format Definitions for Output Tape from Data Simulation Program. 



User A, Frame Definition 


Output Tape from Data 
Simulation Program 

Related Channel No. 
In Satellite Telemetry 
System (See Figure 2) 

Channel Description 

Comments 

Channel 




1 

None 

Flags Pertaining to 

These flags simulate those 



Data and Ground Time 

that are produced by the 
STARS lines. 

2, 3, 4 

None 

Ground Time 

Assumes three channels are 
needed to specify the ground 
time 

5 

1 

Experiment 1 

1st sample from frame i 

6 

7 

Experiment 1 

2nd sample from frame i 

7 

13 

Experiment 1 

3rd sample from frame i 

8 

19 

Experiment 1 

4th sample from frame i 

9 

25 

Experiment 1 

5th sample from frame i 

10 

31 

Experiment 1 

6th sample from frame i 

11 

37 

Experiment 1 

7th sample from frame i 

12 

43 

Experiment 1 

8th sample from frame i 

13 

3 

Subcommutator Channel 
ID 

Counts from 0 to 31 

14 

21 (Subeom 17) 

Experiment 3 

1st sample from subeom cycle i 

15 

21 (Subeom 25) 

Experiment 3 

2nd sample from subeom cycle i 


User B, Frame Definition 


i 

None 

Flags 

Same as described above 

2, 3, 4 

None 

Ground Time 

Same as described above 

5 

9 

Experiment 2 

1st sample from frame i 

6 

33 

Experiment 2 

2nd sample from frame i 

7, 8, 9 

45, 46, 47 

Frame sync ID 
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II 



Experiment Data Characteristics 

Four periodic functions are automatically available to the user. These are sine wave, stair- 
step, ramp, and constant. Figure 3 illustrates these four functions. Any combination of channels 

within a frame may be assigned to a particular 
curve. The assignment of multiple channels to 
a given curve is equivalent to supercommuta- 
tion. In addition, more than one curve can be 
assigned to a given channel. Hence, if an ex- 
periment is to be active for only the last two- 
thirds of the file, one curve with a constant 
value of 0 would be specified for the start of the 
file, and the desired data curve would be speci- 
fied to begin at approximately the point where 
one- third of the file has been generated. 

Experiment data curves can be defined for 
subcommutator channels as well as for main 
frame channels. Here again, full flexibility is 
provided to the user in selecting combinations 
of subcommutator channels for different data 
curves. 

In case the four functions incorporated in 
the program are not suitable, the user may sup- 
ply a subroutine for generating special functions, 
or a table-lookup technique may be used. More 
information on this option is provided in the 
next section. 

Once the value of the curve is computed, sensor noise may be added. The additive noise is as- 
sumed to have a normal distribution with zero mean and a standard deviation specified by the user. 
For example, if a sine wave is chosen, the actual values would be distributed as shown in Figure 4. 

Two options are available for generating the data curves. One is the case in which the channel 
positions in the format defined for the output tape are directly related to the time at which the 
curve is sampled. The other case is the one in which the time at which the curve is sampled is 
independent of the channel position defined for the output tape. The former case would likely be 
selected for simulating a tape which has all of the channels per frame as the actual telemetry sys- 
tem, whereas the latter option is likely to be chosen if the simulated tape is not defined as having 
the same number or arrangement of channels per frame as the actual telemetry system. In the 
latter case, a constant time increment, input by the user, is used as the sampling interval for each 
channel assigned to a given curve. Through the foregoing options and the flexibility permitted in 
defining the data for a given channel, virtually any format designated by the user, including intermixed 
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Figure 3— Experiment data curve options. 
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formats as used on the OGO satellites, may be 
defined in such a manner as to provide realistic 
data values for the various curves involved. 


User Coding 

Options exist to permit user coding to gen- 
erate experiment data curves and data flags. For 
generating experiment data, the user provides 
a subroutine called USRSUB. Once each frame, 
the main program calls the subroutine and pro- 
vides the current ground time, record number, 
and frame number. The user subroutine then 
computes the value of the curve for insertion in 
the output tape record and then returns control 
to the main program. 


EXPERIMENT DATA CURVE 1 


NOISE DISTRIBUTION 
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X (0 Xi + AiSin|^p. (t-Ci)J+n 
WHERE: 

Ac, Pi, Ci ARE AS DEFINED IN FIGURE 3, 

J n 2 /2 a 2 
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a IS AN INPUT PARAMETER, 

AND n RANGES FROM 0— 5a 


ll P ( n ) 


=H- 

-2 a - c 


( REPRESENTS THE PROBABILITY 
DENSITY FUNCTION FOR THE 
AMOUNT OF NOISE " n " THAT 
IS TO BE ADDED TO THE 
DATA VALUE '‘0” 


1-P 


Figure 4— Experiment data with sensor noise. 


In a similar manner, the user may provide 
a FLGSUB subroutine for generating a data flag. 

Again, once each frame, the main program calls 
the subroutine and provides the current ground 
time, record number, frame number, and num- 
ber of errors in a frame synchronization pattern. The user subroutine then computes the 
value of the flag for insertion in the output record and returns control to the main program. 


Code Conversion 

Each tape may have a tape label record, and each file may have a file label record. These 
label records may be specified as either UNIVAC 1107 FIELDATA or IBM BCD code. This selec- 
tion is based on an input parameter for each label definition. 

Satellite Clock Specification 

Readings from a satellite clock may be obtained by considering the clock to be another data 
curve. The starting value of the clock, as is trueforall data curves, is an input parameter. Nor- 
mally, the stair-step type of curve will be chosen for the clock simulation. Since the amplitude of 
the stair-step determines the increment of the clock update, it would be assigned a value of one. 
Depending on the other input parameters, the clock updates may be made to be either synchronous 
or asynchronous. The term synchronous, as used here, refers to the case in which the time source 
for the clock update is synchronized with, or taken from, the same source as that used for gener- 
ating the telemetry frames. The term asynchronous is used when the time source for the clock 
update is independent of the time source for the telemetry frame generator. In the former case, 
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the clock is essentially a frame counter, whereas in the asynchronous case the number of frames 
between clock updates will likely be greater than one and will fluctuate throughout the file. 

If the satellite clock characteristics are more complex than can be simulated through use of 
the stair-step curve, a user subroutine may be substituted. 

Ground Time 

An associated ground time is generated for each frame of data. It is used, among other things, 
to determine the point along the data curve where the sample is to be taken for a given frame for 
those channels which are time-dependent. Ground time is simulated by specifying the start time 
and the elapsed time per frame. Frames will continue to be generated until the user- specified 
stop time is reached for a given file. The ground time generated for a given frame relates to the 
first bit of the first channel defined for that frame. Various types of errors in ground time, de- 
scribed later on, may be simulated; however, these errors do not affect the proper selection of 
the sampling points for the data channels as previously mentioned. 

Data Perturbations 

Ground Signal Processing 

Satellite telemetry data are converted from their analog form to a digital magnetic tape suit- 
able for direct computer input by means of a STARS (Satellite Telemetry Automatic Reduction 
System) processor. In addition, the STARS processor decodes the ground time and generates 
flags with each frame of data to indicate the data and ground time integrity. The flags indicate: 

a. number of errors in the frame synchronization pattern for the given frame. 

b. incorrect BCD or serial decimal time. 

c. one or more parity errors within the frame. 

d. loss of frame synchronization or subcommutator synchronization. 

The operation of the STARS processor is simulated by the computer program, including the 
logic used to maintain frame and subframe synchronization. One or more losses of frame or sub- 
frame synchronization during a given file can be made to occur, depending on the user f s choice of 
input parameters. Also, any combination of the above flags may be generated and recorded on the 
output tape in the designated format. 


Transmission Noise 

Transmission noise is simulated according to input parameters such as bit error rates, sig- 
nal blanking, and bit slippage. The bit error rate for a given file is applied to each data sample 
by generating a random number between zero and one for each bit of the sample value. When the 
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random number is less than the bit error percentage, the corresponding bit is complemented 
(thereby resulting in an error). 

Signal blanking simulates loss of signal, and hence the loss of synchronization during the 
analog-to-digital conversion, for short durations. The bit error percentage during these intervals 
is then temporarily 50%. The frequency of occurrence of signal blanking is controlled by an input 
parameter, but the elapsed time of each occurrence is selected at random and the number of frames 
lost can vary between 5 and 20 frames. 

Bit slippage is the condition where the time between successive bits in the telemetry stream 
changes to the extent that the cumulative effect is at least equal to one-half the bit time. The num- 
ber of bits per telemetry frame is thus in error. This usually causes the STARS processor to lose 
synchronization, as described previously. Forward and backward bit slippages of single and mul- 
tiple bits may be generated by inputting a bit slippage probability for the file. At the beginning of 
each frame, a random number is generated and tested against the bit slippage percentage input by 
the user. If the random number is less than the slippage percentage, the position of the slip within 
the frame and the magnitude and direction of slip are computed, using additional random numbers. 


Satellite Telemetry System Malfunctions 

Many satellite telemetry malfunctions may be simulated. Two such cases are presented here. 

Subcommutator slippage is defined as an incorrect updating of the satellite subcommutator 
position. Both the probability of an erroneous subcommutator updating and the value of the in- 
correct increment are input parameters. Each time the subcommutator is sampled, a determina- 
tion is made according to the specified probability as to whether an error is to be introduced. 

The direction of the position error may be either positive or negative, and may be independently 
specified for each of five subcommutators. 

Irregularities can be made to occur in simulating the satellite clock readings. Random errors 
which are normally distributed can be specified with any frequency of occurrence, as described 
previously under Experiment Data Characteristics. However, if other than random noise is de- 
sired, it can likely be achieved by defining additional curves for the same channel. Such things 
as forward time jumps, temporary changes in clock speed, and clock re- setting can all be accom- 
modated in this manner. 


Ground Equipment Malfunctions 

Problem files which result from ground equipment malfunctions can easily be obtained. One 
such possibility is erroneous ground time. Four types of errors, in any combination, can be re- 
flected in the ground time values. The frequency of occurrence of each type of error is controlled 
by the user's input parameter. The four types of time errors will be controlled by error per- 
centages, which are input to the program. The errors consist of bias errors, rate errors, single 
time discontinuities, and suspect time. Bias errors, for example, may be introduced by the time 
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encoder or decoder. Rate errors simulate telemetry bit rate instability, or time decoder fly- 
wheeling due to loss of signal. Single time discontinuities occur during momentary decoder mal- 
functions. Suspect time is indicated by the time quality flag which, if requested, is inserted with 
each frame of data. In actual practice, suspect time covers the case where the ground time appears 
to be correct, but it does not fully meet all the validity checks that are performed by the STARS 
line in the analog- to-digital conversion process. 

Other types of ground data processing equipment (both STARS processing and digital com- 
puters) malfunctions may be simulated. Such items as incorrect tape formats (described next), 
incorrect record length, parity, and density can all be introduced by the user. Record lengths may 
be short or long, with the size randomly chosen between zero and twice the normal length. Tape 
parity errors are simulated by generating a record of opposite parity to that specified. Tape 
density errors are handled in the same manner by generating a record of incorrect density 200 or 
556 characters per inch. 


Operator Errors 

Several types of operator errors which result in incorrect tape formats are provided, such 
as the omission of an end-of-file (EOF) mark, or the presence of an extra end-of-file mark at the 
end of the data file. Another type of error is the omission of a file label record at the beginning of 
a file. Note that equipment malfunctions could cause the above errors in a similar manner. 

The user can exercise the above options to extend the normal formatting capability of the 
program. These options allow the user to obtain one file having two different formats, as is pos- 
sible with the OGO satellite. In this case the second format would be defined as a second file by 
having the user specify no end-of-file mark for the first file, and no label record for the second 
file. The generated data would then appear as one consecutive file. 

Tape and Printer Outputs 

The tape format will, in general, appear as in Figure 5. The format may be modified as just 
described. All input parameters for a given run are listed with suitable identification. This is 
followed by printouts of each data value for selected channels. In addition, every n th output tape 
record may be printed if desired. Error conditions are also listed. These include time errors, 
bit slippage, signal blanking, subcommutator slippage, tape parity errors, etc. Appropriate 
identification, e.g. the type of error and frame number where the error occurred, is included with 
each error. At the completion of each file summary, statistics of data quality are printed. 

Computer Time Required 

Because of the complexity of the simulation, no simple formula has been derived for the 
UNIVAC 1107 time required for a given problem. However, to provide some feel for the time 
involved, results of an actual computer run are given. A simulation for the Atmosphere Explorer- 
B satellite was performed with the following parameters: 
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Figure 5 — Tape format. 


48 words per frame, 

9 bits per word, 

32 frames per record, and 
10 4 frames simulated. 

In this case, an average of 100 milliseconds of computer time was required for each frame simulated. 


User Information 

To fully exploit the potential benefits offered by the Data Simulation Program, all NASA per- 
sonnel (including programmers, analysts, supervisors, and experimenters) involved in defining 
computer program specifications and writing computer programs are encouraged to avail them- 
selves of this service. Any NASA center may request a copy of the program and appropriate 
documentation, in order to run the program on a UNI VAC 1107 or 1108 computer, which may be 
more readily accessible than the GSFC facility. For those desirous of using the GSFC 1107 com- 
puter, such requests will be accommodated on a time permitting basis. Requests should be di- 
rected to the Data Simulation Project, Data Processing Branch, Information Processing Division, 
Goddard Space Flight Center, Greenbelt, Maryland. 


(Manuscript received March 10, 1966) 
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"The aero?7autical and space activities of the United States shall be 
conducted so as to contribute ... to the expansion of human knowl- 
edge of phe?jomena in the atmosphere and space. The Administration 
shall provide for the widest practicable and appropriate dissemination 
of information concerning its activities and the results thereof .” 

— National Aeronautics and Space Act of 1958 
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